home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pem-mime-02.txt < prev    next >
Encoding:
Text File  |  1993-04-20  |  24.0 KB  |  823 lines
  1.  
  2.  
  3.           Network Working Group                            Steve Crocker
  4.           Internet Draft                                       Ned Freed
  5.                                                            Marshall Rose
  6.  
  7.                                MIME-PEM Interaction
  8.  
  9.                              Thu Apr 18 14:00:00 1993
  10.  
  11.  
  12.  
  13.  
  14.           1.  Status of this Memo
  15.  
  16.  
  17.           This document is an Internet Draft.  Internet Drafts are
  18.           working documents of the Internet Engineering Task Force
  19.           (IETF), its Areas, and its Working Groups.  Note that other
  20.           groups may also distribute working documents as Internet
  21.           Drafts.
  22.  
  23.  
  24.           Internet Drafts are valid for a maximum of six months and may
  25.           be updated, replaced, or obsoleted by other documents at any
  26.           time.  It is inappropriate to use Internet Drafts as reference
  27.           material or to cite them other than as a "work in progress".
  28.  
  29.  
  30.           2.  Abstract
  31.  
  32.           This memo defines a framework for interaction between MIME and
  33.           PEM services.  MIME [3], an acronym for "Multipurpose Internet
  34.           Mail Extensions", defines the format of the contents of
  35.           Internet mail messages and provides for multi-part textual and
  36.           non-textual message bodies.  PEM [4-7], an acronym for
  37.           "Privacy Enhanced Mail", provides message encryption and
  38.           authentication services for Internet mail messages.
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.           draft                MIME-PEM Interaction               Apr 93
  60.  
  61.  
  62.           3.  Introduction
  63.  
  64.  
  65.           An Internet electronic mail message consists of two parts: the
  66.           headers and the body.  The headers form a collection of
  67.           field/value pairs structured according to RFC 822 [1], whilst
  68.           the body, if structured, is defined according to MIME.  MIME
  69.           does not provide encryption or authentication services.
  70.  
  71.  
  72.           PEM allows encryption and authentication services to be
  73.           applied to the contents of electronic mail messages but does
  74.           not provide message structuring or type labelling facilities.
  75.  
  76.  
  77.           This memo defines a framework whereby the services provided by
  78.           MIME and PEM are used in a complementary fashion.  The
  79.           resulting combined service provides encryption and
  80.           authentication services for multi-part text and non-text
  81.           messages.
  82.  
  83.  
  84.           MIME-PEM interaction is provided for by defining four new MIME
  85.           content types: multipart/pem, application/pem, message/pem-
  86.           clear, and application/pem-encrypted.  Then the relationship
  87.           between MIME and PEM is described in terms of two functions:
  88.           message composition and message delivery.
  89.  
  90.  
  91.           4.  Definiton of new Content Types
  92.  
  93.  
  94.           4.1.  Multipart/pem Content Type Definition
  95.  
  96.  
  97.           (1)  MIME type name: multipart
  98.  
  99.           (2)  MIME subtype name: pem
  100.  
  101.           (3)  Required parameters: boundary, privacy
  102.  
  103.           (4)  Optional parameters: none
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.           Expires Oct 18, 1993                                  [Page 2]
  113.  
  114.  
  115.  
  116.  
  117.  
  118.           draft                MIME-PEM Interaction               Apr 93
  119.  
  120.  
  121.           (5)  Encoding considerations: Either 7bit, 8bit, or binary
  122.                encoding may be used, depending on the nested part
  123.                encodings and transport limitations.
  124.  
  125.           (6)  Security Considerations: see [4]
  126.  
  127.  
  128.           This subtype of multipart always contains two body parts. The
  129.           contents of the first body part contains the privacy-enhanced
  130.           content and corresponds to the <pemtext> production as defined
  131.           in section 9 of [4]. The first part's content type is either
  132.           message/pem-clear or application/pem-encrypted.
  133.  
  134.  
  135.           The second part describes the privacy enhancement which was
  136.           applied to the first body part. The second part's content type
  137.           is always application/pem.
  138.  
  139.  
  140.           The syntax and semantics of the boundary parameter is defined
  141.           in [3].
  142.  
  143.  
  144.           The syntax of the privacy parameter, using the ABNF notation
  145.           of [1], is:
  146.  
  147.                privacy-value   ::= "ENCRYPTED"
  148.                                  / "MIC-ONLY"
  149.  
  150.           with each value conveying the intent of the PEM Proc-Type:
  151.           field as specified in section 4.6.1.1 of [4].  Note that MIC-
  152.           CLEAR is not provided directly; it is subsumed by the
  153.           combination of MIC-ONLY and the MIME Content-Transfer-Encoding
  154.           mechanism that is available to any body part.
  155.  
  156.  
  157.           4.2.  Message/pem-clear Content Type Definition
  158.  
  159.  
  160.           (1)  MIME type name: message
  161.  
  162.           (2)  MIME subtype name: pem-clear
  163.  
  164.           (3)  Required parameters: none
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.           Expires Oct 18, 1993                                  [Page 3]
  172.  
  173.  
  174.  
  175.  
  176.  
  177.           draft                MIME-PEM Interaction               Apr 93
  178.  
  179.  
  180.           (4)  Optional parameters: none
  181.  
  182.           (5)  Encoding considerations: Any transport-compatible
  183.                encoding capable of accomodating the range of data
  184.                present in a particular message may be used.  Use of
  185.                quoted-printable is strongly recommended in order to
  186.                guard against inadvertent corruption that would otherwise
  187.                lead to validation failures.
  188.  
  189.           (6)  Security Considerations: see [4]
  190.  
  191.  
  192.           The canonical form of this content type corresponds to the
  193.           <pemtext> after integrity checks have been computed.
  194.  
  195.  
  196.           This content type occurs only inside of a multipart/pem
  197.           content type.
  198.  
  199.  
  200.           4.3.  Application/pem-encrypted Content Type Definition
  201.  
  202.  
  203.           (1)  MIME type name: application
  204.  
  205.           (2)  MIME subtype name: pem-encrypted
  206.  
  207.           (3)  Required parameters: none
  208.  
  209.           (4)  Optional parameters: none
  210.  
  211.           (5)  Encoding considerations: Any transport-compatible
  212.                encoding capable of accomodating binary data may be used.
  213.                However, base64 is recommended in order to be backwards-
  214.                compatible with the original PEM encoding conventions.
  215.  
  216.           (6)  Security Considerations: see [4]
  217.  
  218.  
  219.           The canonical form of this content type corresponds to the
  220.           <pemtext> after encryption processing.
  221.  
  222.  
  223.           This content type occurs only inside of a multipart/pem
  224.           content type.
  225.  
  226.  
  227.  
  228.  
  229.  
  230.           Expires Oct 18, 1993                                  [Page 4]
  231.  
  232.  
  233.  
  234.  
  235.  
  236.           draft                MIME-PEM Interaction               Apr 93
  237.  
  238.  
  239.           4.4.  Application/pem Content Type Definition
  240.  
  241.           (1)  MIME type name: application
  242.  
  243.           (2)  MIME subtype name: pem
  244.  
  245.           (3)  Required parameters: none
  246.  
  247.           (4)  Optional parameters: none
  248.  
  249.           (5)  Encoding considerations: 7bit is always sufficient.
  250.  
  251.           (6)  Security Considerations: see [4]
  252.  
  253.  
  254.           The canonical form of this content type corresponds to the
  255.           <pemhdr> production defined in section 9 of [4].
  256.  
  257.  
  258.           This content type may be used both as a subpart of the
  259.           multipart/pem content type and as an independent bodypart to
  260.           represent certificates and certificate revocation lists
  261.           (CRLs). Certificates and CRLs are not always associated with
  262.           any <pemtext>.
  263.  
  264.  
  265.           5.  Message Composition
  266.  
  267.  
  268.           When a user composes a message, it is the responsibility of
  269.           the user agent to construct a valid MIME message.  In
  270.           particular, Content-Type: and Content-Transfer-Encoding:
  271.           headers should be used wherever they are appropriate.  This
  272.           allows the receiving user agent to unambiguously interpret the
  273.           message body and process it accordingly.
  274.  
  275.  
  276.           Each block of content headers associated with either an RFC822
  277.           <message> or with a MIME <body-part> represents a logical
  278.           place where privacy enhancement can be requested.  A privacy
  279.           enhancement request associated with a particular <message> or
  280.           <body-part> content is taken to apply to the entire content;
  281.           it is not possible to privacy-enhance only a portion of a body
  282.           part.
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.           Expires Oct 18, 1993                                  [Page 5]
  290.  
  291.  
  292.  
  293.  
  294.  
  295.           draft                MIME-PEM Interaction               Apr 93
  296.  
  297.  
  298.           Since the semantics of privacy enhancment requests closely
  299.           parallel those of an additional Content- header, the use of an
  300.           additional Content- header for this purpose is a reasonable,
  301.           but not mandatory, approach.  If a Content- header is used for
  302.           this purpose, this memo suggests that a new header field,
  303.           "Content-Privacy", be used for this purpose.  The syntax of
  304.           this header field corresponds to the <privacy-value>
  305.           production defined above.
  306.  
  307.  
  308.                                        NOTE
  309.                The Content-Privacy header is defined here for
  310.                illustrative purposes only; this RFC does not recommend
  311.                any one specific mechanism. The interface between the
  312.                message composer and pre-submission processing is
  313.                entirely a local matter, and in general any mechanism
  314.                with semantics comparable to a Content-Privacy header can
  315.                be used. More to the point, the interface between the
  316.                message composer and pre-submission processing MUST be
  317.                trustworthy, since the message composer relies on pre-
  318.                submission processing to either perform the requested
  319.                privacy enhancement operation or return an error.
  320.                Regardless of the mechanism chosen, great care should be
  321.                taken to safeguard against both the release of
  322.                information that has not received the requested sort of
  323.                privacy enhancement as well as tampering with the
  324.                enhancement request itself.
  325.  
  326.  
  327.           5.1.  Pre-Submission Algorithm
  328.  
  329.  
  330.           Prior to submission, the user agent first composes a MIME-
  331.           compliant message and then applies this algorithm:
  332.  
  333.  
  334.           (1)  If the content at this (initially top) level has NOT been
  335.                selected for privacy enhancement, the user agent sees if
  336.                the content is either multipart or message.  If so, it
  337.                then recursively applies this algorithm to the
  338.                encapsulated body parts; if not, it terminates processing
  339.                for this content.
  340.  
  341.           (2)  If the content has been selected for privacy enhancement,
  342.                the content is transformed from local form to its MIME
  343.  
  344.  
  345.  
  346.  
  347.  
  348.           Expires Oct 18, 1993                                  [Page 6]
  349.  
  350.  
  351.  
  352.  
  353.  
  354.           draft                MIME-PEM Interaction               Apr 93
  355.  
  356.  
  357.                binary canonical form.  If Content-Transfer-Encoding:
  358.                headers are present the content encoding is reversed as a
  359.                part of this process, leaving only 7BIT, 8BIT, and BINARY
  360.                as possible encodings for all body parts.  This is done
  361.                so that any artifacts introduced by encoding are removed
  362.                and consistent integrity checks will be generated.
  363.  
  364.           (3)  Once binary canonical form has been produced the selected
  365.                privacy-enhancement is performed.  If encryption
  366.                processing is performed an entirely new content is
  367.                generated which replaces the original content. <pemhdr>
  368.                information is also produced by this process.
  369.  
  370.           (4)  A new part is then constructed with the privacy-enhanced
  371.                material as its content.  This part is labelled with a
  372.                content type of either message/pem-clear (if the
  373.                privacy-enhancement is MIC-ONLY) or application/encrypted
  374.                (if the privacy-enhancement is ENCRYPTED).  An
  375.                appropriate transfer encoding is also applied to the
  376.                content and a corresponding Content-Transfer-Encoding:
  377.                header is added to the new part.  Base64 encoding is
  378.                recommended in the case of ENCRYPTED privacy-enhancement
  379.                in order to be backwards-compatible with the original PEM
  380.                conventions.  When MIC-ONLY privacy-enhancement is used a
  381.                transfer encoding other than 7bit must be used only if
  382.                the content data requires it.  However, at a minimum the
  383.                use of the quoted-printable encoding is strongly
  384.                recommended to insure that the message is not damaged in
  385.                transit, which would in turn lead to validation check
  386.                failures and decryption errors.
  387.  
  388.           (5)  Finally, a multipart/pem content is constructed, which
  389.                contains the new part and a corresponding application/pem
  390.                part containing the <pemhdr>. The multipart/pem content
  391.                replaces the original content.
  392.  
  393.  
  394.           6.  Message Delivery
  395.  
  396.  
  397.           When a user receives a message containing a multipart/pem
  398.           content, the user agent may transform the content back into
  399.           its original form prior to privacy-enhancement.  This
  400.           operation, the post-delivery algorithm, is performed by
  401.           reversing the steps performed during the pre-submission
  402.  
  403.  
  404.  
  405.  
  406.  
  407.           Expires Oct 18, 1993                                  [Page 7]
  408.  
  409.  
  410.  
  411.  
  412.  
  413.           draft                MIME-PEM Interaction               Apr 93
  414.  
  415.  
  416.           algorithm.
  417.  
  418.           When the original content is reconstituted into its MIME
  419.           binary canonical form, it may use octet values outside of the
  420.           US-ASCII repertoire and may contain body parts without line
  421.           breaks.  If the user agent replaces the multipart/pem content
  422.           with the original content, then it must select appropriate
  423.           Content-Transfer-Encodings for each body part and add
  424.           corresponding Content-Transfer-Encoding: headers.
  425.  
  426.           Upon successful completion of the post-delivery algorithm for
  427.           each content, the type of privacy enhancement that was in
  428.           effect for that content must be communicated to the user.
  429.           Once again, the semantics of these indicators closely parallel
  430.           those of a Content- header.  If a header is actually used to
  431.           communicate or store this information, it is suggested that a
  432.           new header field, "Content-Annotation," be used for this
  433.           purpose.  The syntax of this suggested header field, using the
  434.           ABNF notation of [1], is:
  435.  
  436.                content-annotation ::= "Content-Annotation" ":"
  437.                                                      annotation-value
  438.  
  439.                annotation-value   ::= <privacy-value> ";" <date-time>
  440.  
  441.           with <privacy-value> corresponding to the privacy-enhancement
  442.           that was in effect during submission, and <date-time>, defined
  443.           in [1] and [2], indicates the date and time when the privacy-
  444.           enhancement was verified by the receiving user agent.
  445.  
  446.                                        NOTE
  447.                As with requests for privacy enhancement to the pre-
  448.                submission algorithm, the path between post-delivery and
  449.                actual display of the message must be a trusted one, lest
  450.                a message be presented that purports to have had a
  451.                <privacy-value> it did not in fact possess.
  452.  
  453.  
  454.           7.  Examples
  455.  
  456.           For example, suppose the following message was being readied
  457.           for submission:
  458.  
  459.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  460.                From:    scrocker@tis.com
  461.  
  462.  
  463.  
  464.  
  465.  
  466.           Expires Oct 18, 1993                                  [Page 8]
  467.  
  468.  
  469.  
  470.  
  471.  
  472.           draft                MIME-PEM Interaction               Apr 93
  473.  
  474.  
  475.                To:      ned@innosoft.com
  476.                Subject: example #1
  477.                MIME-Version:    1.0
  478.                Content-Type:    text/plain; charset=us-ascii
  479.                Content-Privacy: mic-only
  480.  
  481.                Hi Ned.  See how much nicer this works!
  482.  
  483.           After applying pre-submission algorithm, the message submitted
  484.           for delivery would appear as:
  485.  
  486.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  487.                From:    scrocker@tis.com
  488.                To:      ned@innosoft.com
  489.                Subject: example #1
  490.                MIME-Version: 1.0
  491.                Content-Type: multipart/pem; boundary="next-part";
  492.                                             privacy=mic-only
  493.  
  494.  
  495.                --next-part
  496.                Content-Type: message/pem-clear
  497.  
  498.                Content-Type: text/plain; charset=us-ascii
  499.  
  500.                Hi Ned.  See how much nicer this works!
  501.  
  502.                --next-part
  503.                Content-Type: application/pem
  504.  
  505.                Proc-Type: 4,MIC-ONLY
  506.                Originator-ID-Asymmetric: ...,09
  507.                MIC-Info: RSA-MD5,RSA,...
  508.  
  509.                --next-part--
  510.  
  511.  
  512.           After applying the post-delivery algorithm, the resulting
  513.           message would appear as:
  514.  
  515.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  516.                From:    scrocker@tis.com
  517.                To:      ned@innosoft.com
  518.                Subject: example #1
  519.                MIME-Version:      1.0
  520.  
  521.  
  522.  
  523.  
  524.  
  525.           Expires Oct 18, 1993                                  [Page 9]
  526.  
  527.  
  528.  
  529.  
  530.  
  531.           draft                MIME-PEM Interaction               Apr 93
  532.  
  533.  
  534.                Content-Type:      text/plain; charset=us-ascii
  535.                Content-Annotation: mic-only;
  536.                                    Thu, 12 Nov 1992 22:13:40 -0800
  537.                                    (integrity verified)
  538.  
  539.                Hi Ned.  See how much nicer this works!
  540.  
  541.  
  542.  
  543.           The following privacy-enhanced message illustrates how an
  544.           entire message can receive enhancement.
  545.  
  546.                Date:    Mon, 29 Mar 93 13:57:08 -0500
  547.                From:    Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
  548.                To:      Marshall Rose <mrose@dbc.mtview.ca.us>
  549.                Subject: Forwarded integrity Message
  550.                MIME-Version: 1.0
  551.                Content-Type: multipart/pem; boundary="Privacy Boundary";
  552.                                             privacy=mic-only
  553.  
  554.  
  555.                --Privacy Boundary
  556.                Content-Type: message/pem-clear
  557.  
  558.                Content-Type: multipart/mixed; boundary="Middle Boundary"
  559.  
  560.  
  561.                --Middle boundary
  562.                Content-Type: text/plain; charset=us-ascii
  563.  
  564.                The enclosed message was integrity enhanced.
  565.  
  566.                Greg V.
  567.  
  568.                --Middle Boundary
  569.                Content-Type: multipart/pem; boundary="Forwarded Message"
  570.                                             privacy=mic-only
  571.  
  572.  
  573.                --Forwarded Message
  574.                Content-Type: message/pem-clear
  575.  
  576.                Content-Type: message/RFC822
  577.  
  578.                Date:    Mon, 29 Mar 93 13:53:02 -0500
  579.  
  580.  
  581.  
  582.  
  583.  
  584.           Expires Oct 18, 1993                                 [Page 10]
  585.  
  586.  
  587.  
  588.  
  589.  
  590.           draft                MIME-PEM Interaction               Apr 93
  591.  
  592.  
  593.                From:    Ned Freed <ned@innosoft.com>
  594.                To:      Greg Vaudreuil <gvaudre@IETF.CNRI.Reston.VA.US>
  595.                Subject: Minimal PEM Message
  596.  
  597.                This is a mic-clear message using 822 pem.
  598.  
  599.                Greg V.
  600.  
  601.                --Forwarded Message
  602.                Content-Type: application/pem
  603.  
  604.                Proc-Type: 4,MIC-ONLY
  605.                Originator-ID-Asymmetric: ...,09
  606.                MIC-Info: RSA-MD5,RSA,...
  607.  
  608.                --Forwarded Message--
  609.  
  610.                --Middle Boundary--
  611.  
  612.                --Privacy Boundary
  613.                Content-Type: application/pem
  614.  
  615.                Proc-Type: 4,MIC-ONLY
  616.                Originator-ID-Asymmetric: ...,09
  617.                MIC-Info: RSA-MD5,RSA,...
  618.  
  619.                --Privacy Boundary--
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.           Expires Oct 18, 1993                                 [Page 11]
  644.  
  645.  
  646.  
  647.  
  648.  
  649.           draft                MIME-PEM Interaction               Apr 93
  650.  
  651.  
  652.           The following privacy-enhanced message illustrates the use of
  653.           encryption and the application/encrypted content type.
  654.  
  655.                Date:    Mon, 29 Mar 93 14:36:40 -0500
  656.                From:    Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
  657.                To:      Jim Galvin <galvin@TIS.COM>
  658.                Subject: Example Encrypted Message
  659.                MIME-Version: 1.0
  660.                Content-Type: multipart/pem; boundary="PEM Boundary";
  661.                                             privacy=encrypted
  662.  
  663.  
  664.                --PEM Boundary
  665.                Content-Type: application/encrypted
  666.                Content-Transfer-Encoding: base64
  667.  
  668.                8R/EVhZy7OU=
  669.  
  670.                --PEM Boundary
  671.                Content-Type: application/pem
  672.  
  673.                Proc-Type: 4,ENCRYPTED
  674.                DEK-Info: DES-CBC,4C776432D61A9829
  675.                Originator-ID-Asymmetric: ...,09
  676.                Key-Info: RSA,...
  677.                MIC-Info: RSA-MD5,RSA,...
  678.  
  679.                --PEM Boundary--
  680.  
  681.  
  682.           8.  Observations
  683.  
  684.           The use of the pre-submission and post-delivery algorithms to
  685.           combine PEM and MIME capabilities exhibit several properties:
  686.  
  687.           (1)  It allows privacy-enhancement of an arbitrary content,
  688.                not just an entire RFC 822 message.
  689.  
  690.           (2)  For a multipart or message content, it allows the user to
  691.                decide whether the structure of the content should
  692.                receive what sort of privacy-enhancement.
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.           Expires Oct 18, 1993                                 [Page 12]
  703.  
  704.  
  705.  
  706.  
  707.  
  708.           draft                MIME-PEM Interaction               Apr 93
  709.  
  710.  
  711.           (3)  It provides for a messages containing several privacy
  712.                enhanced contents, thereby removing the requirement for
  713.                PEM software to be able to generate or interpret a single
  714.                content which intermixes both unenhanced and enhanced
  715.                components.
  716.  
  717.           (4)  It minimizes confusion when viewing a MIC-ONLY content
  718.                without a PEM-capable user agent.
  719.  
  720.           (5)  It minimizes confusion when viewing a MIC-ONLY content
  721.                with a MIME-capable user agent that is not PEM-capable.
  722.  
  723.  
  724.           9.  Acknowledgements
  725.  
  726.           David H. Crocker suggested the use of a multipart structure
  727.           for MIME-PEM interaction.
  728.  
  729.  
  730.           10.  References
  731.  
  732.           [1]  D.H. Crocker, Standard for the Format of ARPA Internet
  733.                Text Messages, RFC 822, August, 1982.
  734.  
  735.           [2]  R. Braden, Editor, Requirements for Internet Hosts --
  736.                 Application and Support, RFC 1123, October 1989.
  737.  
  738.           [3]  N. Borenstein, N. Freed, Multipurpose Internet Mail
  739.                Extensions, RFC 1341, June 1992.
  740.  
  741.           [4]  J. Linn, Privacy Enhancement for Internet Electronic
  742.                Mail -- Part I: Message Encryption and Authentication
  743.                Procedures, RFC 1421, DEC, February 1993.
  744.  
  745.           [5]  S. Kent, Privacy Enhancement for Internet Electronic
  746.                Mail -- Part II: Certificate-Based Key Management, RFC
  747.                1422, BBN, February 1993.
  748.  
  749.           [6]  D. Balenson, Privacy Enhancement for Internet Electronic
  750.                Mail -- Part III: Algorithms, Modes, and Identifiers, RFC
  751.                1423, TIS, February 1993.
  752.  
  753.           [7]  B. Kaliski, Privacy Enhancement for Internet Electronic
  754.                Mail -- Part IV: Key Certification and Related Services,
  755.                RFC 1424, RSA Laboratories, February 1993.
  756.  
  757.  
  758.  
  759.  
  760.  
  761.           Expires Oct 18, 1993                                 [Page 13]
  762.  
  763.  
  764.  
  765.  
  766.  
  767.           draft                MIME-PEM Interaction               Apr 93
  768.  
  769.  
  770.           11.  Author Addresses
  771.  
  772.           Steve Crocker
  773.           Trusted Information Systems
  774.           email:  crocker@tis.com
  775.  
  776.           Ned Freed
  777.           Innosoft International, Inc.
  778.           250 West First Street, Suite 240
  779.           Claremont, CA 91711
  780.           USA
  781.           Tel:    +1 909 624 7907
  782.           Fax:    +1 909 621 5319
  783.           email:  ned@innosoft.com
  784.  
  785.           Marshall T. Rose
  786.           Dover Beach Consulting, Inc.
  787.           420 Whisman Court
  788.           Moutain View, CA  94043-2186
  789.           Tel:    +1 415 968 1052
  790.           Fax:    +1 415 968 2510
  791.           email:  mrose@dbc.mtview.ca.us
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.           Expires Oct 18, 1993                                 [Page 14]
  821.  
  822.  
  823.